Re: [Thinstation-general] chroot exit leaves mounts mounted
Brought to you by:
doncuppjr
From: Todd P. <pf...@rh...> - 2022-05-04 21:53:14
|
Sorry, what do you mean by "with network stacks?"? I'll check the net device and get back to you, but given that it works when pxe booting, it's unlikely a firmware or driver issue (except maybe the driver isn't loaded ... But why?) On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote: > With network stacks? > > What kind of network adapter? > Possibly a firmware issue. > > > Sent from Yahoo Mail for iPhone > > > Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff > <pf...@rh...> wrote: > Sorry, I just realized that I'd been using the wrong thread for this > subject matter today. > > I've changed my NET_ entries in build to conf to NET_IPV4 equivalents > based on what I could find in various files under build/. This is what I > now have in thinstation.conf.buildtime: > > NET_USE=LAN > NET_USE_DHCP=off > NET_HOSTNAME=tc1 > NET_IPV4_MODE=manual > NET_IPV4_ADDRESS=192.168.1.2/24 > NET_IPV4_GATEWAY=192.168.1.1 > NET_IPV4_DNS1=8.8.8.8 > NET_IPV4_DNS_SEARCH=mydomain.com > > > I then did a new build and then wrote my usb drive with: > > mkgptdrv -p ESP:2g:boot -p l:0:home -o \ > /build/boot-images/grub/efi-source \ > /dev/sdh > > > Boot fails in the same way as before, with the network unconfigured. > > I tried again but with fastboot=false. > > Same thing. No network configuration. > > I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?. > That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg > to look like this: > > menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu > --class os --unrestricted { > set enable_progress_indicator=1 > linux /boot/vmlinuz splash=verbose,theme:default LM=$LM > NET_IPV4_MODE=manual > NET_IPV4_ADDRESS=192.168.1.2/24 > NET_IPV4_GATEWAY=192.168.1.1 > NET_IPV4_DNS="1.1.1.1;2.2.2.2" > NET_IPV4_DNS_SEARCH="mydomain.com" > initrd /boot/initrd > } > > > All those NET_ entries follow the LM=$LM on the same line, it's just split > in this email. > > Booted again, kernel loads, initrd loads, and sometime later it fails > in the same way, with no network configuration. > > What could I possible be doing wrong now? > > > Btw, what does this syntax mean? > > NET_HOSTNAME=tc_* > > > Thanks, > Todd > > > > On Wed, 4 May 2022, Don Cupp wrote: > >> Yep, your getting used to my organization already :) >> >> >> Sent from Yahoo Mail for iPhone >> >> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...> >> wrote: >> >> I assume I should look here for details, yes? >> >> [root@TS_chroot]/build# less >> packages/autonet/etc/udev/scripts/net.sh >> >> >> or, if I were using the networkmanager package, look hereabouts? >> >> ./packages/networkmanager/build/conf/64networkmanager >> >> >> >> On Wed, 4 May 2022, Todd Pfaff wrote: >> >> > omg. I wish I'd asked earlier. So sad for time wasted. >> > >> > I find plenty of old references to NET_(!IPV4)_stuff that I >> was following. I >> > have not yet come across a single googlematch that lead me in >> the >> > NET_IPV4_stuff direction. But now that I grep for NET_IPV >> under build/, I >> > see. >> > >> > Anyway, thanks, better late than never. :) >> > >> > >> > On Wed, 4 May 2022, Don Cupp wrote: >> > >> >> I think it changed to NET_IPV4 prefix a few years back. >> Where did you get >> >> that code? I’ll update it. >> >> >> >> Sent from Yahoo Mail for iPhone >> >> >> >> On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff >> <pf...@rh...> >> >> wrote: >> >> >> >> I first tried this (my usb drive is sdh): >> >> >> >> mkgptdrv -p ESP:2g:boot -p l:0:home -o \ >> >> /build/boot-images/systemd-boot-iso/efi-source >> /dev/sdh >> >> >> >> >> >> I then plugged that usb drive to my thinstation >> machine and >> >> booted. I had >> >> to add the uefi boot entry manually - it wasn't >> autodetected - >> >> not sure if >> >> that is "normal". Booting started but failed, I >> think, because >> >> my network >> >> wasn't configured. I'm aiming for a static network >> >> configuration in this >> >> case. >> >> >> >> I next tried with refind: >> >> >> >> mkgptdrv -p ESP:2g:boot -p l:0:home -o \ >> >> /build/boot-images/refind-iso/efi-source /dev/sdh >> >> >> >> >> >> Same dance, same failure mode - no network >> configuration. >> >> >> >> >> >> I have this in my thinstation.conf.buildtime: >> >> >> >> NET_HOSTNAME=tc003 >> >> NET_IP_ADDRESS=192.168.1.2 >> >> NET_GATEWAY=192.168.1.1 >> >> NET_USE=LAN >> >> NET_USE_DHCP=false >> >> NET_MASK=255.255.255.0 >> >> NET_DNS_SEARCH="mydomain.com" >> >> NET_DNS1=8.8.8.8 >> >> >> >> >> >> What am I missing? Is there anything else I need to >> add to >> >> either >> >> build.conf or thinstation.conf.buildtime to be able to >> efi boot >> >> from a usb >> >> drive with a static network configuration? >> >> >> >> Thanks, >> >> Todd >> >> >> >> >> >> On Wed, 4 May 2022, Todd Pfaff wrote: >> >> >> >> > This is all very interesting. I looked at bt, and >> flash, and >> >> mkgptdrv. Lots >> >> > of archaeological excavation to do. >> >> > >> >> > What is the current recommended way to write a UEFI >> bootable >> >> USB drive from a >> >> > command line in the chroot environment? I don't want >> to >> >> bother with >> >> > Windows+rufus is I can possibly avoid that. >> >> > >> >> > My guess is that I could either use your >> /ts/bin/flash script, >> >> or I could use >> >> > a command line similar to what I see in flash, using >> mkgptdrv >> >> or mkmbrdrv. >> >> > Correct? >> >> > >> >> > In this particular case, since I need to UEFI boot, I >> think I >> >> need mkgptdrv >> >> > rather than mkmbrdrv. Correct? >> >> > >> >> > So, looking at your flash script, you have this entry >> that >> >> uses mkgptdrv: >> >> > >> >> > systemd) >> >> > mkgptdrv -p ESP:2g:boot -p l:0:home -o >> >> > /build/boot-images/systemd-boot-iso/efi-source >> /dev/sdb >> >> > >> >> > >> >> > which leads me to believe that I'll need >> >> boot-images/systemd-boot-iso, and >> >> > based on what I see in the build script, this means >> that I >> >> have to add >> >> > systemd-boot-iso to param bootimages in build.conf. >> Correct? >> >> > >> >> > In general, do you recommend just leaving param >> bootimages >> >> empty so that the >> >> > build script sets it to it's default as it does with >> this >> >> code? >> >> > >> >> > if [ -z "$ts_bootimages" ]; then >> >> > ts_bootimages="syslinux iso pxe refind-iso >> >> systemd-boot-iso grub" >> >> > >> >> > >> >> > Is "systemd-boot-iso" the best option to use for my >> use case >> >> of a UEFI >> >> > bootable USB drive, or is there something else I >> should >> >> consider that's >> >> > already baked into the TS6.2 pie (and hopefully won't >> require >> >> me to make too >> >> > many more educated guesses :). >> >> > >> >> > Thanks, >> >> > Todd >> >> > >> >> > >> >> > On Tue, 3 May 2022, Don Cupp wrote: >> >> > >> >> >> You can also open the file /ts/bin/bt in a text >> editor and >> >> look at the >> >> >> code I use for doing different things. >> >> >> >> >> >> Have a look at >> >> >> >> >> >> wrap_grub_efi() for some clues. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp >> >> <don...@ya...> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> After doing a build, try >> >> >> bt net or bt net-efi >> >> >> to test a pxe boot and possibly an install >> >> >> afterwards, >> >> >> bt image-grub to test your install >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp >> via >> >> Thinstation-general >> >> >> <thi...@li...> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I use fedora. It’s not the code, just how the >> distro is >> >> handling umount. >> >> >> You can see me calling it. On Ubuntu, if I don’t >> use lazy >> >> umount, it hangs >> >> >> the exit. >> >> >> >> >> >> >> >> >> Sent from Yahoo Mail for iPhone >> >> >> >> >> >> On Monday, May 2, 2022, 5:21 PM, Todd Pfaff >> >> <pf...@rh...> >> >> >> wrote: >> >> >>> It's trivial. I just run the following command >> several >> >> times after I >> >> >>> exit >> >> >>> the setup-chroot shell. It has become as quick as >> a !for >> >> in my build >> >> >>> shell. >> >> >>> >> >> >>> for f in `mount|grep thinstation | awk '{print >> $3}'`; do >> >> echo $f; umount >> >> >>> $f; done >> >> >>> >> >> >>> >> >> >>> So, no big deal, just unexpected. >> >> >>> >> >> >>> If we're blaming this on the distro, that really >> suprises >> >> me since you're >> >> >>> basically saying that there are either very few >> ThinStation >> >> users who are >> >> >>> building on a RHEL/CentOS 7 platform, or all the >> other TS >> >> users who do >> >> >>> use >> >> >>> the same distro as me are just suffering in >> silence. >> >> Maybe, who knows. >> >> >>> I'd also find it hard to believe this is distro >> related >> >> given that >> >> >>> setup-chroot is just bash code, and not terribly >> complex >> >> bash code at >> >> >>> that. I'm curious now though: on what distro(s) >> does this >> >> all work >> >> >>> flawlessly? Maybe I'll spin one of those up just >> to ease >> >> my pain. >> >> >>> >> >> >>> Todd >> >> >>> >> >> >>> >> >> >>> On Mon, 2 May 2022, Don Cupp via >> Thinstation-general wrote: >> >> >>> >> >> >>>> Oh the sadness of the various distro >> peculiarities. How >> >> long does it >> >> >>>> take to try and unmount everything? >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd >> Pfaff >> >> >>>> <pf...@rh...> wrote: >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> I'm using thinstation 6.2-Stable, git cloned >> 2022-04-01. >> >> >>>> >> >> >>>> I'm doing builds on a CentOS 7 host. >> >> >>>> >> >> >>>> Something with setup-chroot is faulty. When I >> exit from >> >> setup-chroot, >> >> >>>> it >> >> >>>> does not unmount things like it's supposed to. I >> can >> >> clearly see the >> >> >>>> code >> >> >>>> in setup-chroot in function do_unmounts() that is >> supposed >> >> to do >> >> >>>> the unmount, and I can see from where this is >> called, but >> >> it's not doing >> >> >>>> its job. >> >> >>>> >> >> >>>> This is then somehow leading to various >> problems. We've >> >> seen both /dev/ >> >> >>>> and /dev/pts/ go empty while I've been working >> with ts6.2 >> >> recently. >> >> >>>> >> >> >>>> Todd >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> Thinstation-general mailing list >> >> >>>> Thi...@li... >> >> >>>> >> >> >> https://lists.sourceforge.net/lists/listinfo/thinstation-general >> >> >> >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> Thinstation-general mailing list >> >> >>>> Thi...@li... >> >> >>>> >> >> >> https://lists.sourceforge.net/lists/listinfo/thinstation-general >> >> >>>> >> >> >> >> >> >> _______________________________________________ >> >> >> Thinstation-general mailing list >> >> >> Thi...@li... >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/thinstation-general >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> >> >> > >> > >> >> >> |