Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
On 8/7/20 7:31 am, Alexander Bochmann wrote: > Hi, > > ...on Tue, Jul 07, 2020 at 02:00:38AM +1000, Andrew McGlashan via Dng wrote: > > > After the dist-upgrade, it failed to boot and remained at the ministrants > shell environment after having complained about not being able to find the > /usr file system via it's UUID. > > I have a system mostly like this (minus mdraid) with split root and /usr > on lvm each, and didn't run into your problem. > > My fstab uses /dev/mapper device names instead of UUIDs, but I don't see > why that should make a difference, seeing as it isn't used in the initramfs. Apparently with initramfs-tools it will try to mount /usr if it is in /etc/fstab ... not being able to mount /usr stopped normally boot from progressing further. Using the /dev/mapper device name would likely have been just as good, but I'm not sure as I didn't try that; I adjusted the /usr/share/initramfs-tools/scripts/local-top/lvm2 file to specifically activate the lv so it could be found to be mounted as it should have been. > (On the other hand, I usually use UUIDs too, so there might be a reason it > looks that way, and I just don't remember about it right now...) Yes, that makes sense. I would think that you fixed the problem by using the /dev/mapper entry and I fixed it in the lvm2 script. Either way, I think there is a bug that needs to be fixed with initramfs-tools so that neither adjustment should be necessary. Cheers A. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
Le 07/07/2020 à 18:20, Steve Litt a écrit : > On Tue, 7 Jul 2020 08:41:31 -0700 > Ian Zimmerman wrote: > >> On 2020-07-07 11:26, Steve Litt wrote: >> >>> Void Linux also symlinks all the various *bin directories together, >>> even though it's a runit distro. My objection is this merge forces >>> you to have an initramfs. >> This doesn't sound right, can you explain why you need an initramfs >> with merged /usr if you didn't need it before? >> >> I have a vague recollection of discussing this topic long before, >> maybe with you; sorry if so. >> > You need certain executables, pre-mount, before a separate /usr can be > mounted. These went in /sbin, which is on the root and always > available. If you could mount the root partition, you could proceed. > > But now, if you mount /usr somewhere off the root, and simply have > /sbin symlink to it, those executables aren't available right away. > Imagine if you need the mount executable to mount /usr, but the mount > executable *is* on /usr. Buried shovel. The only way around it is to do > the mounts in initramfs. > Ah we had this discussion years ago! There's not much motivation to put binaries which were traditionnaly under /usr elsewhere than in the root partition nowadays. The main reason for initramfs is, IMHO, for distros to provide disk drivers and filesystems in the form of modules present in the initramfs. They disapear after pivot-root so that only the necessary ones remain in memory. If you don't want an initramfs, then the drivers and filesystems necessary to mount your root partition must be statically linked in the kernel. You can recompile the kernel fot that, but you'll have to do it for every upgrade, and you will need to modify the init sequence because Debian has put some initialisation stuff the initramfs phase. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
On Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: > > > On 8/7/20 7:31 am, Alexander Bochmann wrote: > > Hi, > > > > ...on Tue, Jul 07, 2020 at 02:00:38AM +1000, Andrew McGlashan via Dng wrote: > > > > > After the dist-upgrade, it failed to boot and remained at the > > ministrants shell environment after having complained about not being able > > to find the /usr file system via it's UUID. > > > > I have a system mostly like this (minus mdraid) with split root and /usr > > on lvm each, and didn't run into your problem. > > > > My fstab uses /dev/mapper device names instead of UUIDs, but I don't see > > why that should make a difference, seeing as it isn't used in the initramfs. > > Apparently with initramfs-tools it will try to mount /usr if it is in > /etc/fstab ... not being able to mount /usr stopped normally boot from > progressing further. > > Using the /dev/mapper device name would likely have been just as good, but > I'm not sure as I didn't try that; I adjusted the > /usr/share/initramfs-tools/scripts/local-top/lvm2 file > to specifically activate the lv so it could be found to be mounted as it > should have been. > > > (On the other hand, I usually use UUIDs too, so there might be a reason it > > looks that way, and I just don't remember about it right now...) > > Yes, that makes sense. > > I would think that you fixed the problem by using the /dev/mapper > entry and I fixed it in the lvm2 script. I quite agree. There's a bug that needs fixing for Devuan, but not Debian. I may delay upgrading until it's fixed. My /boot is on an old-style RAID by itself, so either copy can be used directly. My /usr, by the way, is on lvm2 on RAID. Do I need both adjustments? -- hendrik > Either way, I think there is a bug that needs to be fixed with > initramfs-tools so that neither adjustment should be necessary. Quite agree. This is a bug in Devuan that originates in Debian but is not considered a bug there. So, as I understand it, if /usr is mentioned in /etc/fstab, initramfstools will generate an initramfs that tries to mount /usr. And that will succeed it /etc/fstab specifies /usr by the /dev/mapper name, but not by the uuid? So updating /etc/fstab to use the /dev/mapper name instead of a uuid will make things work? Even for LVM2 partitions? As it happens, my /etc/fstab alrady uses /dev/mapper names, though it uses a uuid for /boot. At the very least, this should be mentioned in the upgrade instructions. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
On 8/7/20 10:07 pm, Hendrik Boom wrote: > On Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: >> >> >> On 8/7/20 7:31 am, Alexander Bochmann wrote: >>> Hi, >>> >>> ...on Tue, Jul 07, 2020 at 02:00:38AM +1000, Andrew McGlashan via Dng wrote: >>> >>> > After the dist-upgrade, it failed to boot and remained at the >>> ministrants shell environment after having complained about not being able >>> to find the /usr file system via it's UUID. >>> >>> I have a system mostly like this (minus mdraid) with split root and /usr >>> on lvm each, and didn't run into your problem. >>> >>> My fstab uses /dev/mapper device names instead of UUIDs, but I don't see >>> why that should make a difference, seeing as it isn't used in the initramfs. >> >> Apparently with initramfs-tools it will try to mount /usr if it is in >> /etc/fstab ... not being able to mount /usr stopped normally boot from >> progressing further. >> >> Using the /dev/mapper device name would likely have been just as good, but >> I'm not sure as I didn't try that; I adjusted the >> /usr/share/initramfs-tools/scripts/local-top/lvm2 file >> to specifically activate the lv so it could be found to be mounted as it >> should have been. >> >>> (On the other hand, I usually use UUIDs too, so there might be a reason it >>> looks that way, and I just don't remember about it right now...) >> >> Yes, that makes sense. >> >> I would think that you fixed the problem by using the /dev/mapper >> entry and I fixed it in the lvm2 script. > > > I quite agree. There's a bug that needs fixing for Devuan, but not > Debian. > I may delay upgrading until it's fixed. Not sure it will get fixed... :( - it seems that the problem is a bit of an edge case and won't effect anybody whom doesn't split /usr from root. - if they have split them and they don't "merge" them, - then the problem /may/ only arise if UUIDs are used for mount reference in /etc/fstab. I don't really like my fix, but I'll probably merge /usr into root myself next time I'm onsite where that machine lives to avoid future issues. > My /boot is on an old-style RAID by itself, so either copy can be used > directly. > > My /usr, by the way, is on lvm2 on RAID. > Do I need both adjustments? I would think that the /dev/mapper/VG-LV in /etc/fstab would probably be fine. Otherwise, expand the root file system LV (hopefully you have space), boot from a LIVE USB and move /usr back to root as well as remove the /usr entry in your /etc/fstab file. Once /usr is back inside the root filesystem, then there is no need to keep the /usr lv. Cheers A. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
...on Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: > Using the /dev/mapper device name would likely have been just as good, but > I'm not sure as I didn't try that I'll try if using UUIDs in the fstab makes a difference in the boot process later tonight (and maybe why, if it indeed does). The system has been migrated from hardware into a VM some time ago, so I can recover easily. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] OT: mpv drops GNOME support
https://linuxreviews.org/Mpv_drops_GNOME_support ... am I the only one to see similarities with the systemd situation? And both out of the same stable! Jim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: mpv drops GNOME support
The link mentions that gnome apps are "supposed to be used under gnome" and after I upgraded to beowulf, I found that evince was unusable (I use xfce). The rendering engine was working, but the defaults were unusable and it failed to save new defaults. The error messages referred to lacking permissions to access/write a bunch of files in .local and .cache which completely existed and were totally accessible. Switching to "atril" worked great. --Tim On Wednesday, July 8, 2020, 2:57:46 PM EDT, Jim Jackson wrote: https://linuxreviews.org/Mpv_drops_GNOME_support ... am I the only one to see similarities with the systemd situation? And both out of the same stable! Jim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot, left at initramfs shell -- with fix and query
...on Wed, Jul 08, 2020 at 05:12:54PM +0200, Alexander Bochmann wrote: > ...on Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: > > Using the /dev/mapper device name would likely have been just as good, > but I'm not sure as I didn't try that > I'll try if using UUIDs in the fstab makes a difference in the > boot process later tonight (and maybe why, if it indeed does). So yes, using a UUID for a split /usr mount (on lvm) in the fstab totally doesn't work. I'm landing in the "Begin: Running /scripts/local-block ... done." loop too, ending with "ALERT! UUID= does not exist. Dropping to a shell!" I apparently changed my fstab from UUIDs to the /dev/mapper symlinks some time in 2019, way before my upgrade to beowulf (possibly when I migrated that machine into a VM) - so at least for some configurations, this problem has also been present in ascii. Searching for the error messages, the hint to use device names shows up for older Ubuntu versions too, but I haven't found a good explanation why this happens. Initramfs scripting for lvm was never fixed to work with UUIDs? Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: mpv drops GNOME support
Anno domini 20:47:41 Wed, 8 Jul 2020 + (UTC) Tim Wallace via Dng scripsit: > The link mentions that gnome apps are "supposed to be used under gnome" and > after I upgraded to beowulf, I found that evince was unusable (I use xfce). > The rendering engine was working, but the defaults were unusable and it > failed to save new defaults. The error messages referred to lacking > permissions to access/write a bunch of files in .local and .cache which > completely existed and were totally accessible. Switching to "atril" worked > great. > --Tim > > On Wednesday, July 8, 2020, 2:57:46 PM EDT, Jim Jackson > wrote: > > > https://linuxreviews.org/Mpv_drops_GNOME_support > > ... am I the only one to see similarities with the systemd situation? > And both out of the same stable! What a coincidence :) I dropped gnome years ago. nik > > Jim > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
On 2020-07-07 12:20, Steve Litt wrote: > You need certain executables, pre-mount, before a separate /usr can be > mounted. These went in /sbin, which is on the root and always > available. If you could mount the root partition, you could proceed. > > But now, if you mount /usr somewhere off the root, and simply have > /sbin symlink to it, those executables aren't available right away. > Imagine if you need the mount executable to mount /usr, but the mount > executable *is* on /usr. Buried shovel. The only way around it is to > do the mounts in initramfs. Of course I know all of this. And I guess strictly speaking it *is* an answer to my question: if you had this setup and suddenly, without notice, you got switched to a "merged" world, you'd be hosed until you built an initramfs. But that is not how in fact it happens: you have plenty of notice, and plenty of time to change to a scheme with /usr within the root filesystem. And then you don't need an initramfs again, at least not for the above reason. So maybe the real question is, in the merged world, do you have a reason to insist on /usr being a mount point, other than tradition? I know that people used to do rescue tasks via a single-user boot with only the rootfs mounted, but for a long time now it is far easier to do such things by booting into some kind of "live" system on a USB stick. One can make the live system minimal if so inclined, and in fact the minimal Devuan live system is just about perfect for this purpose. -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
